17장. 라인 담당자에서 헤드 셰프로: AI 팀을 지휘하기

출처 — 진 킴·스티브 예기, 『바이브 코딩 프로덕션의 원칙』(제이펍), 17장 (pp. 407~439). 원문 PDF vibe_coding_final_v11_260913.pdf (2026-09-13 판)

지금까지는 개인이 AI 수셰프 한 명과 일하는 법을 다뤘다. 이 장부터는 범위가 팀으로 넓어진다 — 진 킴과 스티브 J. 스피어 박사의 조직 연구(레이어 1·2·3)를 빌려, 에스코피에가 발명한 주방 브리게이드 시스템이 어떻게 AI 에이전트 팀 조직의 청사진이 되는지, 그리고 2024년 DORA 이상 현상이 왜 아키텍처(레이어 3) 문제였는지를 설명한다.

학습 목표

이 장을 끝내면 다음을 할 수 있다.

• 진·스피어의 레이어 1·2·3 프레임워크를 설명하고, 각 레이어가 코드·도구·조직 중 무엇에 대응하는지 구분한다
• 에스코피에의 주방 브리게이드 시스템이 어떤 레이어 3 혁신이었는지 설명하고, 그 원리를 AI 에이전트 조직 패턴에 적용한다
• 제시 영의 온콜 원칙과 아마존·페이스북 사례를 근거로, 바이브 코딩에서 명확한 소유권이 왜 필수인지 논증한다
• 아디다스·부킹닷컴 파일럿 사례를 비교해, 아키텍처(레이어 3)가 AI 도입 효과를 어떻게 증폭하는지 분석한다
• 2024년 DORA 이상 현상과 2025년 후속 연구 결과를 구분하고, 제약 이론으로 그 인과관계를 설명한다

전체 흐름도

17장. 라인 담당자에서 헤드 셰프로: AI 팀을 지휘하기
   │
   ├─▶ §1 헤드 셰프를 위한 심화 수업 — 오케스트레이터로의 진화
   │      개인 → 조직. 진·스피어의 10년 연구 프레임워크 예고
   │
   ├─▶ §2 레이어 1·2·3 — 조직적 배선이 성패를 가른다
   │      일 자체 ─ 도구·인프라 ─ 조직적 배선(가장 안 보이지만 가장 중요)
   │      └─▶ NUMMI(같은 레이어 1·2로 세계 최고 공장 재탄생) · 이사벨라 vs 빈센트(7장 복습)
   │
   ├─▶ §3 레이어 3을 바꾸는 AI
   │      프런트엔드/백엔드 분리 근거 흔들림 → 조직화 질문이 병렬성과 함께 커진다
   │
   ├─▶ §4 레이어 2에서 개선해야 할 영역들 — 에이전트 조직 패턴
   │      서브 에이전트·생성자/검증자·작업 그래프 매니저 / 문서 공유·에이전트 간 통신
   │      └─▶ 개인 에이전트 팀 5개를 조율하는 '레이어 3의 레이어 3' 예고
   │
   ├─▶ §5 1890년대, 헤드 셰프의 탄생 — 에스코피에의 브리게이드 시스템
   │      한 냄비 주방 → 전문화된 스테이션 → 병렬 작업 + 명확한 커리어 경로
   │
   ├─▶ §6 제시가 온콜일 때 누가 바이브 코딩을 할 수 있을까 — 소유권과 피드백 루프
   │      "내가 온콜일 땐 바이브 코딩 없다" → 만든 사람이 운영한다
   │      └─▶ 페이스북(2007)·아마존(1995~2005, 마이크로서비스 전환) 사례
   │
   ├─▶ §7 모두가 바이브 코딩을 하는 시대 — 민주화와 조직 재편
   │      비개발자도 바이브 코딩 → 엔지니어는 표준·검토의 책임자로
   │
   ├─▶ §8 생성형 AI와 DORA 지표 — 2024년 이상 현상
   │      DORA 4대 지표 소개 → 2024년: AI 도입↑ → 안정성↓·처리량↓
   │
   ├─▶ §9 아디다스 700명 파일럿 복습하기 — 제약 이론의 실적용
   │      행복한 시간(47%→65%) ↔ 아키텍처 차이(80% vs 30%) → 제약 이론(오븐이 고장났는데 다른 스테이션을 고쳐봐야 소용없다)
   │
   ├─▶ §10 부킹닷컴 파일럿 복습하기
   │      태스크 기반 에이전트 3종(스키마 위저드·마이그레이션·리뷰) → 워크숍이 핵심
   │
   └─▶ §11 사회 기술의 대가, 그리고 결론
          웨스트럼의 다섯 특징 + 이 장의 다섯 핵심 실천 사항
          └─▶ 다음 장: 바이브 코딩 문화 조성하기(18장)

0. 용어 사전

참고 — 위쪽 5개는 이 장을 읽기 전에 알아야 하는 선행 용어다. 이 장은 「헤드 셰프」·「AI 수셰프」·「FAAFO」·「이사벨라·빈센트 셰프」·「DORA 이상 현상」을 이미 아는 상태에서, 그것을 개인에서 팀·조직 규모로 확장한다. 낯설면 각 정의 옆에 적힌 장을 먼저 보라.

1. 헤드 셰프를 위한 심화 수업 — 오케스트레이터로의 진화

이 장은 곧바로 독자를 부른다 — "헤드 셰프 여러분, 다시 돌아온 것을 환영합니다." 지금까지는 AI 수셰프 한 명과 일하는 법을 마스터했다는 전제다. 이제 질문이 바뀐다 — 단일 스테이션이 아니라 주방 전체, 혹은 여러 레스토랑 체인 전체를 관리하라는 미션이 떨어지면 어떻게 할 것인가. 저자들은 이 장에서 다수의 디지털 어시스턴트로 이뤄진 교향악단을 지휘하는 오케스트레이터로 진화하는 방법을 다룬다고 예고한다 — 구성이 복잡한 프로젝트에서 여러 AI 에이전트 팀을 어떻게 조율할지, AI가 모든 것을 가속할 때 왜 조직 구조가 더 중요해지는지, 그리고 개발자 각자가 자신의 AI 함대를 거느릴 때 벌어지는 난장판을 피하는 법이다.

이 확장을 뒷받침하는 것은 진 킴과 MIT 슬론 스쿨의 스티브 J. 스피어 박사가 10년간 진행한 고성과 조직 연구다. 두 사람은 토요타 생산 시스템 같은 고속 학습 시스템 전문가(스피어)와 데브옵스 전문가(킴)의 조합으로, "성공하는 조직과 고전하는 조직을 가르는 차이는 무엇인가"라는 질문에서 출발해 그 결실을 『Wiring the Winning Organization』(2023)에 담았다. 이 장의 나머지 전부는 이 책이 제시하는 프레임워크 — 일이 이뤄지는 3개의 레이어 — 위에 서 있다.

이 장을 마칠 때쯤 독자는 여러 AI 어시스턴트를 관리하는 방법뿐 아니라, 인간 팀과 AI 팀이 함께 번영하는 시스템을 설계하는 방법을 익히게 된다. 그리고 온콜 동료를 새벽 2시에 깨우는 원인 제공자가 되지 않는 법, 조직이 대규모 FAAFO를 달성하는 환경을 조성하는 능력도 갖추게 된다.

2. 레이어 1·2·3 — 조직적 배선이 성패를 가른다

진과 스피어의 연구는 어떤 조직에서든 일이 세 개의 레이어에서 이뤄진다고 결론짓는다.

레이어 1(일 자체) — 가치가 실제로 창출되는 곳이다. 병원의 환자, 접시 위의 정갈한 요리, 개발 중인 코드, 프로덕션에서 실행 중인 바이너리, 사용자에게 전달되는 기능이 여기 속한다.

레이어 2(도구와 인프라) — 일을 수행할 때 필요한 장비다. 병원의 MRI·CT, 주방의 오븐·믹서·칼·수비드 머신, IT 업계의 IDE·컴파일러·쿠버네티스·CI/CD 파이프라인·버전 관리 시스템이 여기 속한다. 레이어 2를 능숙하게 다루는 것은 숙련된 실무자의 중요한 특징이다.

레이어 3(조직적 배선) — 눈에 가장 안 띄지만 가장 중요한 레이어다. 일을 어떻게 구조화·분할·통합하는지를 정의한다. 시스템 아키텍처, 조직 설계, 커뮤니케이션 방법, 워크플로와 절차, 표준, 인터페이스가 모두 여기 속한다. 요리에 비유하면 주방 내 집기 배치, 직원별 역할, 주문부터 요리가 나오기까지의 절차, 스테이션 간 정보 흐름, 리더십과 문화다. 소프트웨어 세계에서는 소프트웨어 아키텍처 자체가 레이어 3에 속한다 — "네 팀이 모여 컴파일러를 만들면, 네 단계로 구성된 컴파일러가 만들어진다"는 콘웨이의 법칙이 이를 잘 보여준다.

레이어 3이 결정적인 이유는 레이어 1·2가 아무리 좋아도 성패를 가르는 것이 종종 레이어 3이기 때문이다. 캘리포니아 프리몬트의 NUMMI 사례가 그 증거다 — 토요타는 GM의 공장 중 가장 성과가 나쁘던 곳을 가져와 노동력(레이어 1)과 공장 설비(레이어 2)를 그대로 유지한 채, 불과 2년 만에 세계적 수준의 시설로 바꿔놓았다. 바뀐 것은 관리 시스템·워크플로·커뮤니케이션 패턴·문제 해결 메커니즘·리더 훈련, 즉 레이어 3뿐이었다. 이 책 2부에서 다룬 나사의 아폴로 프로그램(교신 담당을 우주 비행 경험자로 한정한 결정)도 같은 레이어 3 결정이었다.

이 책 7장 §2가 소개한 이사벨라와 빈센트 셰프를 다시 불러올 대목이 여기다. 둘은 똑같이 뛰어난 직원(레이어 1)과 같은 주방(레이어 2)을 가지고 있었다. 7장은 이 대조를 피드백 루프의 차이로 설명했지만, 이 장은 같은 차이를 레이어 3의 언어로 다시 읽는다 — 이사벨라는 워크플로를 세심하게 계획하고 스테이션마다 명확한 책임을 부여하며 구성 요소를 어떻게 통합할지 결정했다(레이어 3에서 이뤄지는 결정들). 그 결과가 FAAFO였다. 반면 빈센트는 모든 사람을 그냥 한데 모아두고 자연스러운 협업을 기대했고, 엉망진창과 나쁜 FAAFO로 끝났다. 둘의 유일한 차이는 레이어 3에서 내린 결정들뿐이었다.

개발자 개인 기여자는 전통적으로 레이어 1·2를 중심으로 활동해왔다 — 주어진 도구로 코드를 작성하거나 작업을 수행하는 데 집중했다. 아키텍처, 팀 구조, 팀 간 커뮤니케이션, 프로젝트 계획 같은 레이어 3 결정은 보통 관리자·아키텍트·고위 리더의 영역이었다. 그런데 바이브 코딩은, 특히 에이전트를 사용하면 모든 개발자를 레이어 3에서 결정을 내리는 위치로 끌어올린다 — AI 어시스턴트(혹은 10개)에게 문제의 여러 부분에서 작업하라고 지시하다 보면 아키텍트가 될 수밖에 없기 때문이다. 아키텍트처럼 사고하기, 겹치지 않게 일감 쪼개기, 빠른 피드백 루프 만들기, 의존성 관리하기, 디지털 어시스턴트와 소통할 명확한 커뮤니케이션 프로토콜 만들기 — 이런 레이어 3 기술은 바이브 코딩 세계에서 더 이상 선택 사항이 아니다.

3. 레이어 3을 바꾸는 AI

바이브 코딩 때문에 팀과 시스템을 조직하고 아키텍처를 설계하는 방식 자체가 달라질 수 있다. 프런트엔드 팀과 백엔드 팀의 분리가 좋은 예다 — 두 팀이 분리되면 API 설계, 코드 위치(저장소를 분리할지 합칠지), 작업 동기화·병합 방법에 대한 합의가 필요해진다. 산업계 대부분이 이 분리를 택한 이유는 양쪽 모두 평생을 바쳐도 부족할 만큼 복잡도가 커졌기 때문이었다 — 이 역시 레이어 3에서 일어난 문제였고, 업계는 회의·문서화·프로세스로 이를 해결해왔다.

그런데 AI가 프런트엔드와 백엔드 모두를 다룰 수 있다면, 과거 그 분리를 위해 내렸던 결정들이 오히려 장애물이 될 수 있다. 프런트엔드·백엔드용 에이전트가 각각 존재하고 서로 다른 개발자가 운영한다면, 두 에이전트가 겹치는 영역의 정보를 공유하고 작업을 조정·동기화할 수 있을까? 차라리 에이전트 하나가 양쪽 모두를 처리하는 편이 클라이언트/서버 간 통신 성능을 높일 수도 있다. 인간 개발자도 프런트엔드·백엔드 저장소가 분리돼 있으면 변경이 어려워 합치고 싶어지는 것과 같은 이치다.

에이전트를 어떻게 조직할 것인지, 에이전트 집단들을 어떻게 조직할 것인지 같은 질문은 병렬성이 증가할수록 매우 중요해진다. 이 새로운 레벨의 조직화는 에이전트 간 커뮤니케이션, AI가 만든 산출물에 대한 표준 합의, 그리고 팀·사람·프로젝트마다 여러 AI 에이전트를 조직적으로 움직일 수 있게 하는 레이어 2 도구에 대한 니즈를 불러온다. 저자들은 레이어 3을 담당하는 조직적 배선이 앞으로 몇 년간 크게 변화할 것이라 예상한다 — 코딩이 더 이상 병목이 아니게 되면 조직의 나머지 부분이 병목이 되기 때문이다. 데브옵스 등장 때도 비슷한 일이 있었다 — 클라우드와 CI/CD 덕분에 개발자 생산성이 크게 오르면서 QA·보안 절차가 SDLC 왼쪽으로 이동(shift left)하고, "코드를 만든 개발자가 운영까지 직접 맡는다"는 원칙이 자리 잡았다. AI는 더 큰 변화를 약속한다 — 코드 생성이 병목이 아니게 되면, 압박은 제품 관리·디자인·QA 같은 다른 조직으로 이동해 새로운 병목을 만들 것이다.

4. 레이어 2에서 개선해야 할 영역들 — 에이전트 조직 패턴

저자들은 레이어 2 도구가 여전히 미흡하고, 그로 인해 레이어 3에 조직화 부담이 더해진다고 지적한다. 아직 에이전트 함대를 매끄럽게 조직하고 상호작용을 관리하며 충돌을 자동으로 해결해줄 정교한 대시보드는 없다 — 초창기 셰프들이 다중 스테이션 주방 운영법을 알아내려 고군분투하던 것과 비슷하다. 지금은 공유 드라이브·메신저로 프로젝트 정보를 주고받고, 소스 코드 곳곳에 AGENTS.md 파일이 흩어져 있고, 커스텀 배시 스크립트를 만들고, 수동으로 깃 브랜치를 관리하고, 에이전트가 막히지 않았는지 확인하려 알림을 듣고, SDLC 각 단계 산출물을 수동으로 검토하는 임기응변식 운영이 일반적이다.

저자들이 파악 중인 레이어 2 도구 패턴은 다음과 같다.

MCP(9장 §3·10장 §6·§8이 먼저 정의)는 여기서 에이전트 간 통신 계층으로 다시 등장한다. 저자들은 가까운 미래에 더 나은 개발자 경험을 제공할 에이전트 군집 관리 대시보드와 조율 도구가 나올 것으로 보지만, 지금 당장은 없으니 위 패턴을 직접 구축해보라고 권한다.

나만의 에이전트 팀을 운영하는 것도 이미 충분히 어렵다. 그런데 더 어려운 것은 인간 동료들 역시 각자 자신의 에이전트 팀을 운영한다는 사실이다. 다섯 명으로 이뤄진 팀에서 개발자 각자가 여러 에이전트를 돌리고 있다면, 5개의 에이전트 클러스터를 조율할 수 있어야 한다 — 이는 아직 해결되지 않은 문제다. 저자들은 바로 이 지점에서 각 개발자가 소유한 에이전트 클러스터에 걸쳐 '레이어 3의 레이어 3'이 작동하는 조정 패턴들이 나타날 것이라 전망한다. 인간이 에이전트를 중개하지 않게 되면, 편견 없이 인간의 지시를 받아들이는 협력적인 에이전트 집단이 알아서 작업할 것이고, 작업 속도는 지금보다 훨씬 빨라질 것이다.

5. 1890년대, 헤드 셰프의 탄생 — 에스코피에의 브리게이드 시스템

책 전반에서 복잡한 주방 운영을 감독하는 헤드 셰프를 예시로 썼지만, 헤드 셰프가 과거부터 있던 것은 아니다. 1870년대로 거슬러 가면 전혀 다른 풍경을 만난다 — 외식은 여관이나 선술집에서 이뤄졌고, 음식은 한 냄비에서 조리하는 수준이었다. 큰 호텔에 요리사가 여럿 있어도 대부분 한 가지 요리만 내는 거대한 가정식 주방처럼 운영됐다. 모두가 같은 음식을 먹었고, 전문화된 스테이션도 표준화된 프로세스도 없었다 — 오귀스트 에스코피에가 1890년대에 요리 방식을 혁신하기 전까지는.

에스코피에의 주방 브리게이드 시스템은 혁신적인 레이어 3 돌파구였고, 오늘날에도 여전히 위력을 발휘한다. 이 발명은 헨리 포드의 조립 라인, 다이이치 오노의 토요타 생산 방식에 필적하는 혁신이었다. 에스코피에는 프랑스-프로이센 전쟁 중 프랑스 군대에서 복무하며, 명확한 계층구조와 표준화된 프로토콜로 군부대가 복잡한 작전을 조율하는 모습을 지켜보았다. 그 이전에는 음식 준비가 제한적이었다 — 식당은 그날 만들던 음식을 그대로 제공했고, 부유한 사람들은 맞춤형 요리사를 따로 고용했다. 메뉴판을 보고 원하는 음식을 주문한다는 개념 자체가 없었다 — 당시의 구식 레이어 3 아키텍처가 다양성과 복잡성을 지원할 수 없었기 때문이다.

에스코피에는 전문화된 스테이션들로 이뤄진 모듈식 시스템을 만들어, 각 스테이션이 명확한 업무를 수행하게 했다. 모든 요리사가 모든 일을 한꺼번에 처리하려 동분서주하는 대신, 한 사람은 소스만, 다른 한 사람은 생선만, 또 다른 사람은 차가운 요리만 관리하도록 역할을 나눴다. 각 스테이션은 특정 작업에 최적화된 작은 주방이 되어 주방 전체와 정확히 맞물려 작동했다(런던 사보이 호텔, 1890년 최초 도입). 원문의 작업 그래프 그림(그림 17.1)이 이 병렬 구조를 보여준다 — 야채 준비·단백질 조리·가르드망제(찬 요리)·앙트르메티에(채소·수프)·포아소니에(생선)·로티시에(구이)·파티시에(디저트)가 각자 정해진 시간(예: 단백질 25분, 고기 휴지 8분) 안에 독립적으로 작업하고, 헤드 셰프가 패스(최종 플레이팅·품질 관리)에서 이를 통합해 5분 안에 서빙으로 넘긴다. 수석 셰프라고도 불리는 헤드 셰프는 메뉴(스펙)를 설계하고 표준화된 프로세스(프로토콜)를 수립하며, 모든 스테이션이 부드럽게 연결(인터페이스)되도록 주방을 감독한다. 수셰프는 운영 관리자 역할로 실시간 조정과 품질 관리를 담당한다.

브리게이드 시스템 덕분에 레스토랑은 거대한 메뉴를 일관된 품질로 제공하고 수백 가지 요리를 수천 명에게 낼 수 있게 됐다. 역할이 표준화되면서 주니어 요리사 → 스테이션 전문화 → 수셰프 승진 → 헤드 셰프라는 명확한 커리어 경로도 생겼다. 이 시스템이 혁신으로 인정받는 진짜 이유는 그것이 열어놓은 확장 가능성이다 — 저녁만 운영하던 레스토랑이 아침·점심·저녁 전부를 서비스해야 한다면 직원 일부를 3교대 수셰프로 승진시키면 되고, 500명 연회가 있다면 (개발자들이 쿠버네티스 파드를 추가하듯) 스테이션 담당 셰프를 늘리면 된다. 근본 체계는 그대로 유지한 채 사람 수만 늘려 문제를 해결하는 것 — 이것이 뛰어난 레이어 3 아키텍처가 지닌, 운영 규모와 무관하게 적응하는 특징이다.

요리 프로그램에서 냄비가 끓어 넘치고 셰프들이 서로 소리 지르며 음식이 안 나와 손님이 자리를 뜨는 광란 상태를 본 적이 있다면, 그것이 바로 레이어 3이 잘못됐을 때의 결과다. 오늘날 모든 개발자는 리더다 — 에스코피에의 위업을 재현할 수도, 요리 프로그램의 혼란을 재현할 수도 있다.

6. 제시가 온콜일 때 누가 바이브 코딩을 할 수 있을까 — 소유권과 피드백 루프

로봇 셰프들은 민첩하지만, 그중 하나가 크렘브륄레를 절인 청어로 장식하겠다고 제멋대로 실행해버리면 화난 손님에게 사과할 사람은 헤드 셰프다. 이 비유는 바이브 코딩의 핵심 위험을 짚는다 — 누구나 작동하는 코드를 만들 수 있게 되면, 창작(코드 작성)과 결과를 잇는 중요한 피드백 경로가 실수로 끊어질 수 있다.

실무 예제(형태 B — 판단 시나리오) 상황 — 깃랩의 수석 엔지니어 제시 영은 자신이 온콜(장애 발생 시 즉시 호출을 받는 담당)일 때는 명확한 선을 긋는다 — "내가 온콜일 때는 바이브 코딩은 없다." 코딩 과정에 마찰이 없으면 책임이 너무 분산될 수 있다는 것을 그는 알고 있었다. 잘못된 접근 — 팀 전체가 머리를 비운 채 무분별하게 바이브 코딩만으로 덜 익은 코드를 양산하고, 그 코드가 그대로 상용 서버에 배포된다. 장애가 나면 애초에 그 코드를 이해하지 못한 사람이 새벽 2시에 불을 꺼야 한다. 올바른 접근 — 바이브 코딩으로 작업했다면 그 코드를 배포하는 날의 온콜 담당자는 작성한 사람 자신이어야 한다 — "만든 사람이 운영까지 한다." 이렇게 피드백 루프를 촘촘히 설계해두면, 내 결정으로 벌어진 결과는 온전히 내 책임이 된다. 왜 — 헤드 셰프의 판단 — 동료가 아니라 자신이 새벽 2시에 깨어난다는 사실만큼 확실한 되먹임은 없다. 자신의 실수로 온콜 동료가 반복해서 깨어난다면, 동료들이 알아서 바이브 코딩에 조정이 필요하다고 알려줄 것이다.

명확한 소유권과 빠른 피드백 루프는 바이브 코딩이 만드는 새벽 장애에 대한 좋은 해결책이다. 개발자가 운영 전담 팀의 무선 호출기를 넘겨받아 온콜 순환에 참여하는 조직도 늘어날 것으로 저자들은 본다. 이렇게 기존 역할이 흐려지는 현상을 인재 스택 붕괴라 부른다 — 운영 팀과 개발 팀의 역할 붕괴가 그 한 예다. 데브옵스가 그랬듯, 개발자가 운영에 관여하는 것은 운영 역할이 사라진다는 뜻이 아니라 개발자가 운영을 더 많이 수행하게 된다는 뜻이다.

역사적 증거도 있다. 2007년경 페이스북은 지속적인 장애로 고통받다가, 엔지니어링 매니저와 아키텍트를 온콜 교대에 포함시키는 급진적 변화를 택했다. 1년 안에 대부분의 문제가 사라졌다 — 매니저와 아키텍트가 자신이 매일 내리는 결정이 하류에 어떤 영향을 미치는지 처음으로 직접 경험했고, 스스로 이해관계자라는 인식의 전환이 일어났기 때문이다. 아마존의 개발자들은 1995년부터 2005년까지 약 10년간 24시간 온콜 상태였다 — 부담스러웠지만 덕분에 시장 변화와 장애 모두에 능숙하게 대응할 수 있었다. 코드를 만드는 사람과 그것을 쓰고 운영하는 사람 사이에 레이어가 적을수록 피드백 루프는 빨라진다. 아마존이 모놀리스에서 마이크로서비스로 전환하며 모든 서비스에 책임자를 지정하고 온콜 연락망에 그 연락처를 포함시킨 것도 같은 원리였다 — 장애가 나면 "그 서비스를 만든 팀을 찾는" 대신 "지금 온콜로 배정된 개인은 누구인가"로 질문이 바뀌었다.

엔지니어링 과정에 바이브 코딩을 도입할 때는 "에이전트가 작성한 모든 변경 사항은 인간이 책임진다"는 명확한 지침이 반드시 필요하다. 장애가 났을 때 책임질 사람을 바로 가리킬 수 없다면 소유권을 빼앗긴 것이나 다름없다 — 소유권 없는 엔지니어링은 도박이고, AI를 많이 쓸수록 그 도박 중독은 심해진다. 프로덕트 매니저·UX 디자이너 같은 비엔지니어가 바이브 코딩을 하고 온콜 교대에 들어가는 새로운 업무 패턴도 등장할 것이다 — 이 소유권 문제는 저자들도 "한 권짜리 책이 필요할 정도"라고 인정하며 이 장에서는 다루지 않는다고 밝힌다.

7. 모두가 바이브 코딩을 하는 시대 — 민주화와 조직 재편

그렇다면 앞으로 누가 바이브 코딩을 하게 될까? 저자들은 모든 지식 노동자가 머지않아 바이브 코딩을 시작할 것이라 본다. 에이전트 덕분에 코딩은 민주화됐고 상품화도 진행 중이다. 그럼에도 소프트웨어 개발은 여전히 큰 작업이고 장기적 관점이 필요하다 — 소프트웨어 엔지니어는 바로 이 일을 위해 훈련받은 사람들이다. 저자들은 앞으로 엔지니어들이 다른 모든 사람이 더 효과적으로 코딩할 수 있도록 돕는 특별한 역할을 맡을 것이라 전망한다.

아키텍처 설계·성능 최적화 같은 엔지니어링 지식을 갖춘 개발자는 AI를 다루는 데서도, 사람과 협업하는 데서도 레이어 3의 역할을 하게 된다. UX 디자이너·프로젝트 관리자·IT 운영·기술 문서 작성·QA·재무·영업·마케팅 전문가를 비롯해 레이어 1에 있는 모든 사람이 바이브 코딩의 세계로 뛰어들 것이다. 이들이 만드는 소프트웨어 대부분은 대시보드 같은 내부용이라 프로덕션 환경까지 가지 않겠지만, 회사 입장에서는 가치를 창출하는 것이 마찬가지라 중요하다. 비개발자 바이브 코더에게 필요한 것은 주니어든 시니어든 엔지니어 한 명이 작업을 검토해주는 것뿐이다. 이것이 바로 민주화다 — 다만 대고객 서비스를 망가뜨리거나 운영 팀의 일을 방해하지 않는 선에서다.

바이브 코딩으로 개인 한 명이 대규모 작업을 해야 할 때는, 적절한 안전장치가 있다는 전제하에 경력과 무관하게 누구나 AI 에이전트를 활용해 원하는 작업을 할 수 있어야 한다. 그러나 바이브 코딩을 팀 전체에 적용하는 방법은 아직 업계 전체가 경험이 부족하고 더 많은 연구가 필요한 영역이다. 엔지니어링 리더가 조직에 바이브 코딩을 안전하게 도입하려 한다면, 지금의 조직도를 그대로 유지하지 못할 수도 있다는 것을 염두에 둬야 한다 — 점진적이면서도 꾸준하게 조직 구조를 바꿔야 AI를 제대로 쓸 수 있다. 제프 베이조스가 아마존에서 만든 피자 두 판 규모의 팀 개념(여러 전문 분야에 걸쳐 활동할 수 있는 권한을 가진 소규모 팀)이 좋은 출발점이다 — 그런 팀 두어 개로 첫 프로젝트를 완수하며 조직 수준의 배움을 모으면, 바이브 코딩을 조직 전체로 확장할 기반이 마련된다.

이 책이 제시한 실천안을 무시하고 무모하게 도입하면 혼란과 끝없는 새벽 2시 호출이 이어질 것이고, 결국 경영진이 바이브 코딩을 금지하는 상황까지 갈 수 있다. 적절한 업무 범위와 명확한 책임 시스템, 촘촘한 피드백 루프, 그리고 개발자가 자신의 작업이 하류에 미치는 영향을 경험할 수 있는 여유를 보장하면, 바이브 코딩을 모두에게 — 심지어 제시의 팀에도 — 지속 가능하게 도입할 수 있다.

8. 생성형 AI와 DORA 지표 — 2024년 이상 현상

헤드 셰프에게는 주방에서 무슨 일이 일어나는지에 대한 명확한 측정치가 필요하다. 진은 2013년 제즈 험블·니콜 포스그렌 박사와 함께 'State of DevOps Research' 프로그램을 출범했고, 지금은 DORA(4장 §0이 먼저 정의)로 불리는 이 연구는 3만 6,000명 규모의 응답자 교차 집단을 장기간 분석해 고성과 기술 조직을 만드는 행동을 규명해왔다 — 보건 산업에서 흡연이 조기 사망·이환율의 주요 원인임을 규명했던 방식과 같은 통계적 접근이다.

DORA 연구는 고성과 조직이 일관되게 보이는 네 가지 핵심 지표를 찾아냈다. 배포 빈도(변경 사항이 프로덕션에 배포되는 빈도), 배포 리드 타임(커밋부터 프로덕션 배포까지 걸리는 시간), 배포 실패율(핫픽스·롤백이 필요한 배포의 비율), 장애 복구 시간(장애 발생 후 복구까지 걸리는 시간)이다. 이 네 지표는 처리량(전달 속도)과 안정성(전달의 신뢰성)이라는 소프트웨어 개발의 두 기둥을 수치화한다. 연구 첫해, 고성과 팀은 그 외 조직 대비 배포를 127배 더 빠르게, 연간 182배 더 많이 수행했고, 배포 실패율은 8배 낮았으며, 장애 복구는 2,293배 더 빨랐다. 더 중요한 것은 이 기술 역량이 비즈니스 성과로 직결됐다는 점이다 — 고성과 조직은 수익성·시장점유율·생산 목표 초과 달성 가능성이 2배 높았고, 직원이 자기 조직을 "일하기 좋은 곳"으로 추천할 가능성도 2배 높았다. DORA 연구는 속도와 안정성이 상충하지 않는다는 것, 그리고 느슨한 아키텍처·빠른 피드백 루프·학습하는 분위기가 성과와 강하게 연관된다는 것을 함께 입증했다.

2024년 DORA 보고서는 업계에 충격을 안겼다 — 생성형 AI 도입이 25% 증가할 때마다 안정성은 7% 악화(더 많은 장애·더 긴 복구 시간)되고, 처리량(배포 빈도·리드 타임)은 1.5% 느려질 것이라는 전망이었다(이것이 4장 §3이 다룬 DORA 이상 현상이다). 이 이상 현상의 정확한 원인은 아무도 모른다 — 2024년 4월에 수집된 데이터는 GPT-4o 등장 이전 시점이었다. 원인이 무엇이든 저자들은 바이브 코딩 등장으로 일을 망치기 더 쉬워졌다는 점, 그리고 이것이 이상 지표와 관련 있다는 데 동의한다. 저자들의 주된 가설은 "AI는 이미 존재하는 프로세스 위생을 그대로 확대 증폭한다"는 것이다 — 조직에 빠른 피드백 루프가 없다면 AI 도입 이후 더 많은 문제가 생길 수밖에 없고, 테스트가 부족한 채 개발자 한 명이 하루 1,000줄 이상을 생성한다면 결과는 뻔하다.

저자들이 이 책에서 지속적으로 강조하는 가이드는 다음과 같다.

• AI가 만든 모든 커밋과 코드는 의도한 대로 동작함을 검증하는 테스트로 자동 검증돼야 한다.
• 코드 변경 크기를 극도로 작게 유지한다 — AI가 한 번에 400줄 이상을 제안해도, 새벽 2시 호출을 각오한 게 아니라면 한 번에 받아들이지 않는다.
• AI가 불필요하게 많은 코드를 만들어내는 것을 허용하지 않는다 — 사소한 수정에 50줄짜리 리팩터링을 제안해도, 가능한 한 가장 작은 변경만 하는 문화를 만든다.
• 위험한 작업을 리뷰할 때는 다양한 모델을 쓴다 — 첫 번째 AI의 환각을 두 번째 AI가 잡아낼 수 있다.
• 코딩 컨벤션을 문서화한다 — AGENTS.md 같은 파일은 사람뿐 아니라 AI도 파싱할 수 있다.

9. 아디다스 개발자 700명의 파일럿 프로그램 복습하기 — 제약 이론의 실적용

6장 §4가 소개한 아디다스 사례(1년간 개발자 500명→700명 확대, 개발자 만족도 91%·생산성 20~30%·일일 참여율 82% 향상)를 이 장은 레이어 3, 즉 조직적 배선의 관점에서 다시 들여다본다.

아디다스의 페르난도 코르나고는 지표 향상 이면의 정성적 경험을 측정하려고 2018년 내부 연구를 다시 검토했다. 그는 업무 시간을 두 모드로 나눴다 — 코딩·테스트·분석·설계·문서 작성처럼 업무 본질과 직접 연관된 행복한 시간(가치 있는 시간)과, 개발 환경 문제·레거시 시스템 문제·권한 요청·불필요한 회의·조직 마찰을 처리하는 짜증 나는 시간(허비한 시간)이다. 2018년과 2024년을 비교하니 행복한 시간의 비중이 47%에서 65%로 늘었다 — 엔지니어가 업무 시간의 약 3분의 2를 가치 있는 일에 쓰게 된 것이다. 그런데 평균에는 함정이 있었다.

실무 예제(형태 B — 판단 시나리오) 상황 — 아디다스 안에서도 팀마다 결과가 크게 갈렸다. 전자상거래를 지원하는 팀들은 느슨하게 결합된 아키텍처와 빠른 피드백 루프로 일했다. 반면 레거시 ERP 시스템에 강하게 결합된 팀은 장애 영향이 너무 커서 1년에 몇 번만 배포할 수 있었고, 테스트에도 수일이 걸렸다. 잘못된 접근 — 레거시 ERP 팀에 코딩 어시스턴트 라이선스만 쥐어주고 생산성이 오르길 기대한다. 페르난도는 실제로 이렇게 말한다 — "만약 제가 레거시 시스템을 다루는 팀에 코파일럿을 써보라고 하면, 구성원들이 '페르난도, 미쳤습니까? 제발 AI 툴 신경 쓰지 말고 먼저 개발 환경과 테스트 프로세스 개선에 도움을 주세요!'라고 성토했을 것입니다." 올바른 접근 — 모듈성과 빠른 피드백 루프라는 아키텍처 전제 조건(레이어 3)부터 갖춘다. 실제로 첫 번째 그룹(느슨한 결합)은 행복한 시간을 최대 80%까지 썼고(IDE 코딩에만 70%를 쓴 팀도 있었다), 두 번째 그룹(강한 결합)은 행복한 시간이 겨우 30%였고 나머지 70%를 대기·마찰 해결에 썼다. 왜 — 제약 이론 — 엘리야후 골드랫이 『THE GOAL』에서 밝혔듯, 제약 지점이 아닌 곳에서 이뤄진 모든 개선은 환상에 불과하다. 오븐이 고장 났는데 오븐을 고치지 않고 플레이팅 스테이션을 최적화해봐야 손님에게 나가는 요리는 늘지 않는다. AI 기반 칼로 채소를 3배 빨리 썰어도 오븐 속도가 그대로면, 손질된 재료만 조리대 위에 쌓여 썩어간다. 테스트가 병목이라면 코드 생성 도구를 아무리 줘도 개발 사이클 전체 시간은 줄지 않는다.

두 그룹의 결정적 차이는 개발자의 실력(레이어 1)도 AI 도구(레이어 2)도 아니었다 — 팀이 실제로 일해야 하는 레이어 3 아키텍처였다. 소프트웨어 업계는 이런 제약을 없애기 위해 수십 년째 씨름해왔다 — 아마존의 연 13만 6,000건 배포를 따라가려는 시도들이 그 예다. 이 과정에서 병목은 순서대로 이동했다 — 클라우드 컴퓨팅이 환경 구축 제약을 없애자 소프트웨어 배포가 새 병목이 됐고, 배포 자동화와 Dev·Ops 공동 책임 체계가 이를 일상적인 작업으로 바꾸자 소프트웨어 테스트(CI/CD, 상시 배포 가능한 빌드)가 다음 병목이 됐으며, 이는 다시 마이크로서비스 같은 모듈형 아키텍처로의 전환을 이끌었다. 바이브 코딩 등장으로 개발자의 잠재적 생산성이 수십 배 늘면서, 이제 병목은 다시 테스트하고 배포하는 능력으로 이동하고 있을지도 모른다 — 저자들은 이것이 바로 DORA 이상 현상의 조짐일 수 있다고 추측한다.

10. 부킹닷컴 파일럿 복습하기 — 태스크 기반 에이전트

6장 §5가 소개한 부킹닷컴 사례를 이 장은 다시 살펴본다. DX(developer experience) 조직의 프로덕트 매니저 브루노 파소스는 3,000명 규모의 개발자 동료가 최고의 환경에서 일하도록 돕는다. 부킹닷컴도 아디다스처럼 AI를 쓴 개발자들에게서 긍정적 경험(코딩 효율성 30% 향상·PR diff 70% 감소·리뷰 시간 단축)을 확인했지만, 이는 더 야심 찬 변화의 출발점일 뿐이었다.

브루노와 그의 팀은 AI를 보조 도구에 머물게 하지 않고, 채팅 기반 코딩에서 코딩 에이전트로 나아갔다. 암스테르담에서 일주일간 열린 워크숍에서 부킹닷컴의 시니어 엔지니어들은 소스그래프와 협력해, 이전에는 몇 달씩 걸리던 작업을 처리하는 태스크 기반 에이전트 세 종류를 만들었다.

• GraphQL 스키마 위저드 — 부킹닷컴의 GraphQL 스키마는 100만 토큰이 넘어 시중 모든 AI 모델이 환각을 일으켰다. 스키마 노드를 지능적으로 탐색해 질문과 연관된 노드만 가져오는 에이전트를 구축해 답변 품질을 높였다.
• 레거시 마이그레이션 도구 — 거대한 레거시 시스템의 1만 줄 넘는 함수를 파싱해 분해하는 전용 에이전트로, 수개월 걸릴 마이그레이션 시간을 줄일 것으로 기대한다.
• 커스터마이즈 가능한 코드 리뷰 에이전트 — 코딩 가이드라인 준수를 강제해 일관성 있는 코드 리뷰를 가능하게 하고, 더 깔끔한 결과물을 더 쉽고 빠르게 병합하게 해준다.

부킹닷컴의 파일럿은 적절한 교육·도구에 조직 차원의 지원이 더해질 때 엔터프라이즈 규모의 바이브 코딩이 실제 비즈니스 가치를 만든다는 것을 보여준다. 브루노는 도구 제공만으로는 충분하지 않고, 목표 지향적이고 실전 중심인 해커톤·워크숍으로 개발 팀 전체를 지원하는 것이 필요하다고 강조했다. 실제로 다양한 해커톤과 워크숍을 거치며, 처음엔 주저하던 개발자들이 열정적인 일일 바이브 코더로 변신하고 FAAFO를 경험했다.

11. 사회 기술의 대가, 그리고 결론

이 장을 마무리하며 저자들은 조직 문화 연구자 론 웨스트럼 박사의 연구를 인용해, 존경할 만한 리더들을 사회 기술의 대가라 부른다. 이들이 공유하는 다섯 가지 특징은 다음과 같다.

• 높은 에너지 — 조직 전체의 AI 도입 추진력을 만들고 열의를 불어넣는다. 소스그래프의 퀸 슬랙은 내부 토큰 사용량 리더보드를 만들어 AI 활용을 '의무'가 아니라 '경쟁적이고 재미있는 활동'으로 바꿨다(자세한 내용은 다음 장에서 다룬다).
• 높은 기준 — 팀 사기를 지키면서도 AI가 생성한 코드를 엄격히 검증하는 절차를 만든다. 아디다스의 페르난도는 속도가 품질을 해치지 않도록 정량적 지표(커밋·PR 개수)와 정성적 피드백(만족도)을 함께 측정해야 한다고 강조했다.
• 큰 일에 능함 — AI가 기존 아키텍처와 프로세스의 장점을 증폭한다는 것을 인식한다. 느슨한 결합 시스템의 팀은 행복한 시간에 80%를 쓰는 반면, 레거시 모놀리스 팀은 답답함을 겪는다는 것을 페르난도가 인지했던 것이 이 특징이다.
• 작은 일에 능함 — 바이브 코딩이 특히 잘 작동하는 작은 사례를 찾아 조직 전체로 확산시킨다. 부킹닷컴의 브루노가 AI 활용 격차를 발견하고 워크숍을 주최해 생산성을 30% 끌어올린 것이 그 예다.
• 현장을 좋아함 — AI를 잘 쓰는 조직 내 전문가·마당발·전도사를 발굴한다. 소스그래프의 리더보드에서 '재무' 부사장이 1위를 차지한 사례를 저자들은 이런 발굴의 예로 든다.

결론. 이제 독자는 AI 수셰프 하나를 관리하는 수준에서 벗어나, 동료가 꾸린 AI 팀과도 조율하고 AI가 마법을 부리는 주방 브리게이드 전체를 조율하는 데 무엇이 필요한지 알게 됐다. 에스코피에의 브리게이드 시스템을 통해 AI 팀을 어떻게 구성해야 하는지, 제시 영의 사례를 통해 AI가 창작 속도를 가속할수록 왜 명확한 소유권이 필수적인지 확인했다. 아디다스의 파일럿과 DORA 이상 지표는 AI 기반 작업의 성패가 결국 아키텍처와 프로세스(레이어 3)가 정한다는 것, 그리고 이 둘이 FAAFO 달성과 빠른 좌절 중 무엇으로 이어질지를 결정한다는 것을 보여줬다.

이 규모 확장은 처음엔 어지러울 수 있지만, 새로운 역할을 맡을 수밖에 없다는 것이 가장 중요한 배움이다. 엔터프라이즈 수준의 바이브 코딩은 워크플로 재설계, 디지털 팀원과 인간 팀원 간 커뮤니케이션 촉진, AI가 내놓은 결과물에 대한 책임을 요구한다 — 이 책임을 져야만 우연이 아닌 재현 가능한 FAAFO를 달성할 수 있다. AI 주방을 이끄는 이가 기억해야 할 핵심 실천 사항은 다섯 가지다 — ① 내면의 헤드 셰프를 받아들여 레이어 3 설계에 집중한다 ② 내면의 에스코피에를 불러내 복잡한 프로젝트를 AI '스테이션'으로 분할하고 인터페이스를 명확히 정의한다 ③ 요리는 AI가 해도 책임은 자신이 진다는 제시 영의 온콜 규칙을 기억한다 ④ 아키텍처가 증폭기임을 인지하고 좋은 레이어 3을 준비한다 ⑤ 부족한 레이어 2 도구를 요구하고 직접 만들며, 지혜롭게 민주화한다 — 비엔지니어가 스스로 코딩을 시작하는 지금, 표준을 세우고 작업을 검토하며 품질을 보장할 책임이 엔지니어에게 있다. 다음 장(18장 「바이브 코딩 문화 조성하기」)은 이 실천을 조직 차원에서 어떻게 문화로 뿌리내릴지를 다룬다.

핵심 개념 정리

실무 체크리스트

• [ ] 우리 조직에서 아키텍처·워크플로·표준 같은 레이어 3 결정을 개발자 각자가 떠맡고 있지 않은가?
• [ ] 프런트엔드·백엔드 팀 분리 같은 과거의 레이어 3 결정이 지금도 여전히 타당한가, 아니면 AI 시대엔 장애물이 됐는가?
• [ ] 여러 에이전트를 조직할 때 서브 에이전트·생성자/검증자·작업 그래프 매니저 같은 패턴 중 무엇을 쓰고 있는가?
• [ ] 에이전트와 사람이 콘텍스트를 나누는 문서(예: AGENTS.md)가 존재하고, 최신 상태로 유지되는가?
• [ ] AI가 작성한 코드가 배포되는 날, 그 코드를 배포한 사람이 온콜 담당자인가?
• [ ] 장애가 났을 때 "이 부분은 AI가 짰다"는 이유로 책임을 회피하는 문화가 자리 잡지 않았는가?
• [ ] 비엔지니어(PM·디자이너 등)가 바이브 코딩을 시작할 때 검토해줄 엔지니어가 지정돼 있는가?
• [ ] 팀의 '행복한 시간' 대 '짜증 나는 시간' 비율을 측정해본 적이 있는가?
• [ ] AI 도구를 도입하기 전에, 진짜 제약 지점(테스트·배포·레거시 결합)이 어디인지부터 확인했는가?
• [ ] 우리 조직에 사회 기술의 대가(높은 에너지·높은 기준·큰/작은 일에 능함·현장 애호)에 해당하는 사람이 있는가?

연습문제

1. 유형: 구분. 레이어 1·2·3의 정의를 각각 설명하고, 이 장에 나온 NUMMI 사례에서 무엇이 바뀌지 않았고(레이어 1·2) 무엇이 바뀌었는지(레이어 3)를 짝지어 설명하라.
2. 유형: 적용. 프런트엔드/백엔드 팀 분리라는 전통적인 레이어 3 결정이, AI가 양쪽을 모두 다룰 수 있게 되면서 왜 장애물이 될 수 있는지 이 장의 논리로 설명하라.
3. 유형: 판단. 제시 영의 "내가 온콜일 땐 바이브 코딩 없다"는 원칙과 "만든 사람이 운영까지 한다"는 원칙이 겉으로는 상반돼 보이지만 실제로는 같은 목표를 향한다. 그 목표가 무엇인지 설명하라.
4. 유형: 사례 분석. 아디다스에서 같은 회사, 같은 AI 도구를 쓰고도 팀마다 '행복한 시간' 비율이 30%와 80%로 갈린 이유를 제약 이론으로 설명하고, 이것이 왜 레이어 1(실력)·레이어 2(도구) 문제가 아닌지 논하라.
5. 유형: 비교. 2024년 DORA 보고서의 이상 현상(안정성·처리량 동시 악화)과 이 장이 제시하는 "AI는 프로세스 위생을 증폭한다"는 가설을 연결해, 느슨하게 결합된 팀과 강하게 결합된 팀이 AI 도입 후 서로 다른 결과를 얻는 이유를 설명하라.

최신 동향 (2026-09 기준)

최신 동향 (검증 2026-09-14) — 이 장이 예고한 "2025년 DORA 연구"는 실제로 발표됐다. 이 장이 제기한 2024년 이상 현상에 대한 저자들의 가설("AI는 기존 프로세스 위생을 증폭한다")과 방향이 일치하는 결과가 나왔다.

• 2025 DORA 보고서(State of AI-assisted Software Development)가 발간되어, 이 장이 예고한 후속 연구의 답을 내놓았다. 핵심 결론은 "AI는 팀을 고치지 않는다 — 이미 있는 것을 증폭할 뿐이다"이다. 강한 팀은 AI로 더 강해지고, 취약한 팀은 기존 문제가 AI로 더 크게 드러난다. 처리량(배포 빈도·리드 타임) 지표는 전년도(2024년 이상 현상)와 달리 AI 도입과 양(+)의 관계로 전환됐다 — 팀과 도구가 AI를 언제·어떻게 쓸지 학습한 결과로 풀이된다. 다만 안정성과의 부정적 관계는 그대로 유지된다 — 이 장의 핵심 논지("빠른 피드백 루프·자동화된 테스트 없이 변경량만 늘리면 불안정해진다")가 다시 한번 확인된 셈이다. DORA 공식 2025 리포트
• 이 장이 인용한 앤트로픽의 클로드 코드 모범 사례 문서는 계속 갱신되고 있으며, 여전히 "계획·명세서 같은 문서를 통한 콘텍스트 공유"를 핵심 권고로 유지한다. Claude Code Best Practices
• 이 장이 언급한 진 킴·스티브 J. 스피어의 『Wiring the Winning Organization』(2023년 11월 출간)은 이 장 전체가 의존하는 레이어 1·2·3 프레임워크의 원 출처로, 현재도 절판되지 않고 유통 중이다. IT Revolution 공식 소개

부록 A. 핵심 비교표

부록 B. 추천 참고 자료

외부 자료 (Tier 1 공식, 생존 확인 2026-09-14)

• 이 장의 프레임워크 원 출처 — Wiring the Winning Organization (IT Revolution 공식 소개)
• 2025 DORA 보고서 공식 페이지 — DORA Research: 2025
• 앤트로픽 클로드 코드 모범 사례(이 장 §4가 인용한 문서 공식 실체) — Claude Code Best Practices
• Model Context Protocol 공식 사이트(이 장 §4가 언급하는 MCP) — modelcontextprotocol.io
• AGENTS.md 공식 표준 사이트(이 장이 여러 차례 언급하는 파일 규약) — agents.md

본 책 연계 챕터

부록 C. 연습문제 풀이

1. (문제 1 정답) 레이어 1(일 자체)은 가치가 실제로 만들어지는 곳(코드·요리·환자), 레이어 2(도구와 인프라)는 일을 수행하는 데 쓰는 장비(IDE·오븐), 레이어 3(조직적 배선)은 일을 어떻게 나누고 통합하는지를 정하는 구조(아키텍처·워크플로·소통 방식)다. NUMMI 사례에서 노동력(레이어 1)과 공장 설비(레이어 2)는 그대로 유지됐다 — 바뀐 것은 관리 시스템·워크플로·커뮤니케이션 패턴·문제 해결 메커니즘·리더 훈련, 즉 레이어 3뿐이었다. 그런데도 2년 만에 세계 최악 수준에서 세계 최고 수준의 공장으로 바뀌었다.
2. (문제 2 정답) 프런트엔드/백엔드 분리는 원래 양쪽 모두를 감당하기엔 복잡도가 너무 커서, 각 팀이 한 영역에 집중하도록 만든 레이어 3 결정이었다. 그런데 AI 에이전트 하나가 양쪽 모두를 다룰 수 있다면, 이 분리가 오히려 에이전트 간 정보 공유와 작업 조정을 어렵게 만드는 장애물이 된다 — 프런트엔드 에이전트와 백엔드 에이전트가 겹치는 영역을 조율해야 하는 새로운 문제가 생기기 때문이다. 차라리 에이전트 하나에게 양쪽 접근 권한을 주는 편이 클라이언트/서버 통신 성능도 높이고 조율 비용도 줄일 수 있다.
3. (문제 3 정답) 두 원칙 모두 "코드를 만드는 사람과 그 결과를 겪는 사람 사이의 거리를 없앤다"는 같은 목표를 향한다. "온콜일 땐 바이브 코딩 없다"는 마찰 없는 코딩이 만드는 책임 분산을 막기 위한 사전 예방이고, "만든 사람이 운영까지 한다"는 이미 만든 코드에 대한 사후 책임 부여다. 둘 다 결국 "내 결정으로 벌어진 결과는 내가 겪는다"는 촘촘한 피드백 루프를 만드는 방법이라는 점에서 같다.
4. (문제 4 정답) 두 팀 모두 같은 회사 소속이라 개발자 실력(레이어 1)의 평균적 차이가 크다고 보기 어렵고, 같은 회사의 AI 도구 투자(레이어 2)도 공유했을 가능성이 높다. 실제 차이는 팀이 일해야 하는 아키텍처(레이어 3)였다 — 전자상거래 팀은 느슨하게 결합돼 빠르게 배포·테스트할 수 있었지만, ERP 팀은 강하게 결합돼 배포에 1년에 몇 번, 테스트에 수일이 걸렸다. 제약 이론에 따르면 테스트·배포가 병목인 팀에 아무리 좋은 코드 생성 도구(레이어 2)를 줘도, 병목 자체를 풀지 않는 한 전체 사이클 시간은 줄지 않는다 — 그래서 이것은 레이어 1·2가 아니라 레이어 3(아키텍처) 문제다.
5. (문제 5 정답) 이 장의 가설은 "AI가 이미 존재하는 프로세스 위생을 그대로 확대 증폭한다"는 것이다. 느슨하게 결합되고 빠른 피드백 루프·자동화된 테스트를 갖춘 팀(좋은 프로세스 위생)은 AI가 그 장점을 증폭해 처리량과 안정성을 함께 얻는다. 반면 강하게 결합되고 테스트가 부족한 팀(나쁜 프로세스 위생)은 AI가 변경량만 늘려 안정성이 더 나빠진다. 2024년 이상 현상(안정성·처리량 동시 악화)은 이런 나쁜 프로세스 위생을 가진 조직이 많이 섞인 평균값이었을 가능성이 크고, 최신 동향에서 다뤘듯 2025년 데이터에서 처리량 관계가 반전된 것은 조직들이 시간이 지나며 AI를 더 적절한 방식으로 통합하는 법을 배운 결과로 해석된다.